-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eliminate artificial supercooled water (rain and cloud) on pressure levels #771
Eliminate artificial supercooled water (rain and cloud) on pressure levels #771
Conversation
@WenMeng-NOAA @HuiyaChuang-NOAA @EricJames-NOAA Here is a draft PR intended to prevent spurious supercooled rain water from appearing on pressure levels. Testing is still ongoing, but feedback / ideas are welcome. Should this new code only be used for RRFS (i.e., |
@jaymes-kenyon Do you have an UPP issue for this PR? If not, please open one. |
(2) Slight change to freezing-temp threshold (now 273.15 K) (3) Revised description in comments (4) Added print statements (temporary)
@gthompsnJCSDA : Here's a draft PR to fix the issue of spurious supercooled rain water; comments are welcome. |
…arlier in MDL2P.f)
…instead of local, hardcoded value
Code has been tested in RRFS 3-km CONUS cases for summer and winter; no GFS tests have been performed.
These results suggest instances of supercooled rain on pressure levels arising purely as an interpolation artifact are relatively rare. In other words, instances of supercooled rain on pressure levels (near the melting level) are usually accompanied by explicit supercooled rain on the overlying model level. It's not known whether this is the expected result; ideas or concerns are welcome. |
(2) Applying adjustments to all hydrometeors
I can think of a really serious potential pitfall. How about the most complex case of more than one crossing (in vertical) of the melting level. I.e., a classic freezing rain profile with the "warm nose?" This really should be checked before proceeding. I believe we would have a really obvious ICICLE case - but I have to check the date, perhaps 2019Feb05. And I agree if the idea works right for rain, then adapt to cloud water as well. For cloud ice going lower in altitude than melting level, I don't think there would be a problem. |
Thanks, @gthompsnJCSDA — I mulled the possibility of a "warm nose" and I think this code will handle that situation appropriately, but I am prepared to test further to confirm. Lines 593–595 require a true melting level to proceed; i.e., "cold above, warm below":
(note that the LL index increases toward the ground, so LL-1 is actually above LL). Given this temperature check, a re-freezing level (i.e., "warm above, cold below")—such as would exist at the base of the "warm nose" in a freezing rain situation—will be untouched by this code. |
… the interpolated value, whichever is greater. This modified approach is reccomended by G. Thompson in order to retain larger values of snow/graupel whenever these mixing ratios increase downward across the pressure level (e.g., snow growth via cloud-drop collection prior to melting).
At the recommendation of @gthompsnJCSDA, I tested this code in a RRFS winter case (8 Feb 2022), then searched for a model column containing a "warm nose" thermal profile with freezing rain at the surface. I found such a column over New England (p = 1002 mb on the lowest-layer midpoint). Using "print" statements, the profiles of temperature (middle column) and Qrain (right column) for 600 mb and below were extracted:
The warm nose (with T > 0C) spans the ~875–975-mb layer. At 850 mb, the "updated" tag indicates where Qrain was modified from its original interpolated value. Otherwise, all other values of Qrain were unaffected by the code in this PR, including the freezing rain at 1000 mb. This suggests that the code retains supercooled rain beneath re-freezing levels, as intended. Note that the values of Qrain aloft ( |
what about those super tiny amounts of rain at 825 and 800 mb? Those appear possibly interpolated values as well. |
@gthompsnJCSDA — That's right. In fact, all of the Qrain values in the table above are the interpolated values that the original UPP code is providing, except at 850 mb. The "<-updated" tag at 850 mb indicates that my code supplied this value by extracting it from the overlying model level, overwriting the original interpolation. Here are some more print statements placed before my code block. First, at 850 mb:
Here at 850 mb, the interpolated value was later replaced by the value from the overlying model level (two orders of magnitude smaller) as a result of my code (see previous table). At 825 mb, small amounts of supercooled rain are present on the adjacent model levels; the interpolated value goes unmodified by my code:
At 800 mb, very small amounts of supercooled rain are present on the adjacent model levels (again, the interpolated value is retained):
Hopefully this is insightful. It looks like our proposed code is behaving as intended. Other concerns/ideas? |
@WenMeng-NOAA — If no further questions/concerns, I think we can continue moving forward with this PR. Testing in RRFS confirms that this code will fix the problem of spurious supercooled water arising purely from interpolation; it leaves most (real) supercooled water intact. No tests have been performed using the GFS. Thanks to @gthompsnJCSDA for helping to describe the original problem and advising on this PR. |
@jaymes-kenyon I will start my testing. Thanks! |
@jaymes-kenyon Can you sync your branch with the latest UPP develop branch? We will process your PR next. Thanks! |
…re_interpolation_update
@WenMeng-NOAA — I just synched with "develop"; hopefully this helps. Thanks! |
@jaymes-kenyon During reviewing your PR, I find a bug of cwm initialization in INITPOST_NETCDF.f. Would you mind to pick up my fix and combine in your PR? My fix is at /scratch1/NCEPDEV/stmp2/Wen.Meng/jaymes/UPP/sorc/ncep_post.fd/INITPOST_NETCDF.f
Thanks! |
Good idea, @WenMeng-NOAA — I added checks for each hydrometeor species. Based on line 512, I think that "C1D" can be formulated the same: if C1D exists, then CWM exists, which also means that all five species exist. But, let me know if I am mistaken. You bug fix has also been added to the PR. |
@jaymes-kenyon Looks good for me. Thanks! |
The UPP RT indicate changed results of these MP variables on isobaric levels for GFS, RRFS, 3DRTMA and HAFS such as:
@jaymes-kenyon I would think the above changes are expected. You may look at RRFS tests at
Please let me know if you see issues from my testing. |
Hey @WenMeng-NOAA — These tests look good to me. All of the changes that were found would be expected. Thanks for the update! |
@jaymes-kenyon Thanks for confirming. |
The UPP RTs were completed on WCOSS2. There will be new baselines needed for gfs, fv3r, 3drtma and hafs with this PR.
|
@FernandoAndrade-NOAA You may start the UPP RT on Orion. See the baseline changes above. |
UPP RTs have completed successfully on Orion, changes in results are consistent with the ones mentioned above for 3drtma, fv3r, fv3hafs, and gfs |
This PR is ready for merging. |
Updates to prevent artificial supercooled rain and cloud water (an aviation hazard) from appearing on pressure levels. This code seeks to fix a problem that was identified/described by Greg Thompson (NCAR) in HRRR pressure-level GRIB2 output. The accompanying figure (linked below) illustrates a scenario in which supercooled rain water can appear in pressure levels when no supercooled rain water is actually present on the adjacent model levels.
isobaric_interpolation.pdf